@asoucar: Why is this notification its own class? Creating a class like this makes it seem like there will be different types of SentFolderNotFound notifications, which is doesn't seem like a normal use case. Why is this not simply create a notification with the correct fields?
#9900 (comment)

Short answer:

We intentionally model recurring domain events as concrete types. A dedicated SentFolderNotFoundNotification encodes the invariant fields (severity, icon, action set, and style) so every call site behaves consistently. It also makes it easier to change these invariants when needed because they’re centralized in one place.

Long answer:

I will split the answer into a few topics.

Why is this notification its own class?

Because the model is intentionally type-driven: each domain event encodes its invariants (severity, icon, actions, and style) once, in a named type. That prevents call-site drift and gives us a single place for localization and UX rules. It also lets us reconstruct the same notification deterministically (e.g., from SentFolderNotFound + accountUuid) to dismiss or re-emit without carrying an ID around.

Creating a class like this makes it seem like there will be different types of SentFolderNotFound notifications, which is doesn't seem like a normal use case.

Not different types, just different instances. This event is account-scoped; two accounts with no Sent folder produce two independent notifications. The factory takes accountUuid for that reason.

Although the notification UI may look the same, they’re distinct because they’re tied to different accounts.

Why is this not simply create a notification with the correct fields?

Ad-hoc field composition pushes UX decisions to every caller and is easy to get wrong (severity/actions/styling drift, inconsistent strings). Encoding those invariants in a dedicated type keeps behavior consistent, testable, and localizable. That's the core reason we avoid a generic "fill the fields" builder.

Let me know if that address your concerns.